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PREFACE 

The  medical  profession  has  many  cumbersome  methods, 
such  as  most  present  medical  codes,  handwritten  records,  and 
the  amount  of  paperwork  involved  in  the  care  of  a  patient. 
These  cumbersome  methods  and  the  establishment  of  Medicare, 
insurance  forms,  and  other  red  tape  which  have  become  an  in- 
tricate part  of  our  society  hinder  the  development  of  computer 
applications  in  the  medical  profession.   This  paper  attempts 
to  cover  the  many  .legal ,  security,  and  technical  problems  that 
arise.   A  general  background  of  computer  applications  in  the 
medical  professions  is  given  with  emphasis  on  the  usefulness 
of  a  medical  history  data  base.   From  such  computer  applica- 
tions, the  medical  profession  will  derive  innumerable  benefits 
These  benefits  include  more  complete  records,  more  individual- 
ized care,  and  efficient  handling  of  paperwork. 
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CHAPTER  1 
INTRODUCTION 

Technology  has  created  many  new  ways  to  cure  people. 
However,  with  these  new  ways  come  new  results,  symptoms,  ques- 
tions, and  answers  that  must  be  recorded.   Politics  have  created 
Medicare  and  Medicaid  and  all  the  red  tape  that  goes  with  it. 
In  this  day  of  rising  prices,  more  people  have  more  insurance 
creating  more  paperwork.   Legal  questions  have  prompted  the  use 
of  more  forms  and  more  complete  forms.   With  all  of  this  addi- 
tional information,  the  highly  technological  medical  profession 
is  still  manually  storing  and  retrieving  information. 

The  hospital  and  private  practices  are  businesses.   How- 
ever, they  often  lack  the  efficiency  of  their  industrial  coun- 
ter parts  even  with  industrial  and  financial  leaders  on  the 
Board  of  Trustees.   With  the  increase  in  cost  and  paperwork,  it 
has  become  increasingly  important  for  the  hospital  to  be  effi- 
cient, but  being  efficient  does  not  necessarily  mean  less  care 
for  the  patient.   Efficiency  could  mean  less  cost  to  the  patient 
and  a  more  individualized  service.   Some  hospitals  have  started 
to  computerize  and  streamline  their  operations .   One  example  is 
the  State  University  Hospital  of  New  York. 

The  State  University  Hospital  of  New  York  and  Downstate 
Medical  Center  is  unique  in  that  it  has  had  its  activities  con- 
trolled by  an  on-line  computer  system,  Thomis  (Total  Hospital 
Operating  and  Medical  Information  System) ,  since  its  opening  in 
1966.   See  in  particular  [22] . 
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The  patient's  previous  history  is  retrieved  from  disk. 
The  computer  then  assigns  a  bed  within  the  contraints  of  sex 
and  locations,  and  preprinted,  self-adhering  labels  for  the 
patient  are  prepared  by  the  computer.   The  nursing  station  is 
notified  that  the  patient  has  arrived  and  the  telephone  office 
is  informed  which  telephone  is  assigned  to  that  patient. 

The  computer  handles  all  transactions  for  both  in- 
patients and  out-patients  although  they  require  to  some  degree 
separate  programs  and  files.   In  the  case  of  a  future  order, 
the  computer  records  the  request  and  then  informs  the  service 
area  on  the  day  the  procedure  is  to  be  performed.   Scheduling 
of  procedures  is  done  for  the  following  service  areas:   Radi- 
ology, Physiology,  Rehabilitation  Medicine,  Physical  Therapy, 
Occupational  Therapy,  Neurology,  Orthopedics,  Plastic  Surgery, 
Inhalation  Therapy,  Psychiatry,  Opthalmalogy ,  and  Operating 
Room. 

When  ordering  from  the  pharmacy,  at  the  same  time  a 
validation  is  printed  out  on  the  ordering  terminal,  a  prescrip- 
tion label  is  printed  containing  all  data  legally  necessary 
and  a  copy  for  the  file  is  made.   The  stock  inventory  of  the  item 
ordered  is  reduced  by  the  appropriate  amount.   If  the  inven- 
tory of  the  item  falls  below  a  specified  level,  the  pharmacy 
is  sent  a  notification  to  reorder.   As  is  the  case  with  all 
orders,  the  patient's  bill  is  updated. 

Thomis  handles  the  reporting  of  quantitative  laboratory 
results  in  the  areas  of  clinical  chemistry,  coagulation,  hema- 
tology, special  hematology,  serology,  and  clinical  isotopes. 
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The  results  are  entered  by  a  clerk  and  then  distributed  by 
Thomis  to  the  appropriate  nursing  stations.   In-patient 
records  are  updated.   Out-patient  records  are  not  usually 
available,  so  their  results  are  summarized  nightly  and  sent 
to  the  medical  records  department. 

Thomis  also  includes  an  accounts  receivable  subsystem, 
management  reports,  extensive  census  reports,  and  statistical 
programs  for  research  and  activity  analysis  [22] . 

Even  with  the  existence  of  such  systems,  computers  are 
not  being  used  to  their  full  potential.   Often  a  single  hospi- 
tal will  attempt  to  computerize  too  much  and  cost,  poor  manage- 
ment, or  lack  of  communication  between  users  and  installers  will 
cause  the  collapse  of  the  project.   Other  times,  several  small 
projects  are  completed  but  are  not  easily  integrated  into  a 
harmonious  unit. 

One  area  that  has  not  been  successful  is  the  storage 
and  retrieval  of  a  complete  and  detailed  patient  history  data 
base.   In  this  paper  an  attempt  is  made  to  design  such  a  data 
base . 

First,  a  description  of  what  the  computer  can  do  to 
help  hospitals  is  given  in  Chapter  2.   Following  this,  in 
Chapter  3,  the  problems  that  will  be  incurred  in  developing 
information  systems  are  briefly  examined.   Then,  in  detail  the 
actual  data  base  for  a  complete  system  is  discussed  with  a 
view  to  the  problems,  expectations,  and  solutions  that  arise. 
Finally,  in  the  conclusion,  the  main  points  are  summarized  and 
implementation  requirements  are  outlined. 


CHAPTER  2 
SCENARIO  OF  A  HOSPITAL  INFORMATION  SYSTEM 

2.1   Hospital  Information  Systems 

Like  a  business,  hospitals  also  suffer  wastes  of  time, 
energy,  and  money  when  computers  are  misapplied.   For  this 
reason,  computers  should  be  applied  in  modular  fashion  to  areas 
with  a  well-defined  purpose.   At  present,  there  are  four  major 
areas  of  hospital  activity  to  which  computers  have  successfully 
been  applied.   The  first,  since  hospitals  are  very  much  a  busi- 
ness, is  data  processing,  where  the  most  widespread  use  of  com- 
puters in  hospitals  is  in  business  systems.   For  example,  busi- 
ness data  processing,  and  in  particular,  data  processing  for 
accounts  receivable,  bills,  and  payroll  are  highly  developed 
outside  the  hospital  and  easily  adapted  to  any  individual 
hospital . 

The  second  and  more  challenging  area  is  that  of  informa- 
tion retrieval.   Here  the  peripheral  display  device  gains  a 
greater  importance  than  the  computer.   It  does  not  matter  how 
economical  a  display  device  is,  if  it  makes  too  much  noise  for 
a  nursing  station,  for  example,  it  does  not  belong  in  the  hos- 
pital . 

While  airlines  have  had  excellent  information  retrieval 
systems  for  many  years,  there  are  as  yet  no  exceptional  models 
in  hospitals,  although  there  are  several  working  models  which 
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will  eventually  be  refined  into  a  smooth  functioning  system. 
However,  a  major  cause  for  frustration  is  the  doctor  who  con- 
tinues to  compile  medical  records  in  a  cumbersome  way.   Never- 
theless, because  of  its  sheer  bulk,  medical  data  will  even- 
tually be  forced  to  be  recorded  in  a  structure  that  will  permit 
computer  manipulation. 

The  third  area  is  management.   Hospitals  have  manage- 
ment staffs  and  often  trustee  groups  whose  members  are  indus- 
trial, financial,  and  professional  leaders  who  have  had  consid- 
erable management  experience  with  computers  and  automation. 
Hence,  the  computer  can  be  used  for  financial  analysis  and 
maintenance  scheduling  within  the  hospital  itself. 

The  fourth  area  is  the  medical-clinical  activity: 
diagnostic,  research,  and  educational.   The  mini-computer  is 
becoming  very  important  in  this  area  as  the  laboratory  control 
element.   The  role  of  the  mini-computer  in  the  laboratory  is 
threefold.   Depending  on  the  size  of  the  laboratory  computer 
and  the  interface  with  the  hospital's  central  computer,  the 
laboratory  computer  is  expected  to  reduce  turnaround  of  test 
results  by  assuming  much  of  the  clerical  work.   In  some  systems 
the  computer  will  assign  patient  lab  numbers,  produce  work  lists, 
quality  control  results,  specimen  tube  labels,  patient  records, 
tally  sheets  for  lab  workload  analysis  and  charge  lists  for  ac- 
counting, and  route  the  output  to  the  proper  location.   All 
this  frees  nurses  and  the  technologist  from  clerical  work  and 
allows  them  to  be  better  utilized. 
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Many  laboratory  procedures  require  computations  to 
convert  raw  data  obtained  from  analytical  instruments  into 
meaningful  information.   Computerization  of  these  procedures, 
especially  in  an  on-line  real  time  system,  reduces  the  chance 
of  a  mathematical  or  transcription  error. 

In  some  cases,  a  computer  can  monitor  analytical  in- 
struments, make  corrections  for  drift  of  baseline,  interpret 
and  chart  repeated  analysis  of  standards,  decide  when  methods 
are  out  of  control  and  when  to  repeat  a  method  that  appears  in 
error  and  relay  error  messages  to  the  technologists. 

The  focus  of  this  paper  will  be  on  the  second  area,  in- 
formation retrieval.   With  the  attempt  to  develop  Hospital  In- 
formation Systems  (HIS)  come  several  large  problems.   The  prob- 
lems are  not  only  technical  but  legal,  behavioral,  social,  and 
political.   Two  problems  that  should  be  mentioned  in  connection 
with  HIS  are  data  processing  requirements  for  health  insurance 
and  the  right  of  privacy  for  patients  in  regard  to  computerized 
data  bases.   Along  with  the  diversity  of  forms  required  by  the 
various  insurance  companies ,  Medicare  and  Medicaid  are  increas- 
ing substantially  the  amount  of  data  processing  for  claims. 
The  processing  of  the  claims  places  a  large  burden  on  the  hos- 
pital and  in  many  cases  forces  them  to  computerize  early. 

Besides  allowing  the  hospital  to  keep  pace,  the  computer 
organizes  and  clarifies  records.   Before  computerization  patient 
records  were  often  disorganized  and  frequently  contained  illeg- 
ible handwritten  records  and   notes.   They  were,  consequently, 
implicitly  safe  from  invasion  of  privacy.   With  computerization, 
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several  problems  will  have  to  be  solved  before  data  bases  are 
widely  accepted.   To  assure  continued  patient  confidence  in 
the  doctor,  the  computer  must  be  covered  by  testimonial  priv- 
ilege.  Also,  the  prevention  of  "leaks"  must  be  considered,  as 
there  will  be  several  programmers,  technicians,  nurses,  etc. 
with  access  to  the  computer.   Policies  need  to  be  developed 
on  the  use  of  medical  information  based  on  the  purpose  of  the 
request,  nature  of  the  information  being  requested,  individ- 
uals or  organizations  requesting  the  information,  and  need  or 
lack  of  need  for  an  informed  written  consent  from  the  patient. 

Hospital  information  can  be  divided  into  two  categor- 
ies:  medical  information  and  administrative  information.   How- 
ever, the  information  in  these  two  categories  is  not  distinct. 
Both  categories  contain  patient  identification  and  a  list  of 
tests  given  to  each  patient,  for  the  results  in  one  category 
and  for  billing  purposes  in  the  other. 

The  most  vital  part  of  all  the  information  is  the  pa- 
tient identification.   For  instance,  should  the  originating 
department  request  a  test  and  the  only  legible  identification 
they  give  is  the  patient's  name,  then  the  Lab  must  call  the 
Information  Center  or  Admitting  Office  to  determine  the  loca- 
tion of  the  patient  in  order  to  transmit  the  results  to  the 
correct  place  and  personnel.   The  carbon  copy  of  the  test  re- 
quest goes  to  the  accounting  department  which  organizes  their 
records  by  patient  numbers,  so  they  too  must  inquire  and  waste 
time  to  gather  the  essential  information. 
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In  short,  to  make  a  Hospital  Information  System  effi- 
cient, administrators  and  physicians  must  have  a  understanding 
of  the  information  flow  in  the  hospital:   they  must  be  aware 
of  what  information  is  needed  by  whom  and  when. 

2.2   Community  Medical  History  Data  Bases 

Previous  discussion  has  shown  that  an  in-house  Hospi- 
tal Information  System  is  desirable,  but  desirability  is  not 
enough.   Present  cost  of  such  a  system  would  prove  economic- 
ally justifiable  to  only  the  largest  institutions  with  over 
1000  beds.   Also,  it  has  been  estimated  that  nearly  70%  of  im- 
portant clinical  observations  are  recorded  outside  the  hospital 
environment  and  at  best  only  a  rough  sketch  of  the  family  med- 
ical history  is  available.   The  solution  to  these  problems  is 
to  extend  the  Hospital  Information  System  to  include  the  entire 
community.   This  would  provide  a  system  not  only  economically 
feasible  to  small  hospitals,  but  also  to  individual  doctors. 
This  Community  Medical  History  Data  Base  would  contain  complete 
records  gathered  from  all  medical  sources,  including  family 
histories.   It  is  also  possible  that  centralized  billing  and 
insurance  processing  is  desirable  and  economical,  but  the  re- 
mainder of  this  paper  will  concentrate  on  the  development  of 
the  Community  Medical  History  Data  Base,  forthwith  referred  to 
as  the  CMHDB.   See  in  particular  [21  and  47] . 

For  the  private  doctor,  CMHDB  must  be  designed  to  com- 
pete with  the  present  system.   It  should  be  just  as  quick  for 
a  nurse  to  retrieve  information  from  CMHDB  as  it  is  presently 
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to  find  the  hard  copy.   The  nurse  must  be  able  to  request  some 
type  of  summary  on  the  patient  for  the  doctor  to  review  before 
meeting  the  patient.   During  the  examination  the  doctor  may 
want  to  request  more  detail,  or,  in  an  emergency,  pertinent 
information  must  be  available  immediately.   All  these  condi- 
tions must  be  met  before  a  CMHDB  becomes  viable  to  the  individ- 
ual doctors.   However,  not  only  must  the  requirements  be  met, 
they  must  be  an  improvement  upon  the  existing  system,  espec- 
ially in  respect  to  retrieval  time  and  completeness  of  records. 
For  this  a  cathode  ray  display  screen  should  be  available  for 
scanning  the  records  for  the  needed  information  without  produc- 
ing a  hard  copy.   This  kind  of  response  time  requires  an  on- 
line system.   By  being  on-line,  the  nurse  does  not  have  to 
worry  if  a  requested  file  for  a  given  appointment  has  arrived. 
In  emergencies  information  is  retrieved  in  seconds.   With  the 
short  response  time,  hard  copy  information  is  minimized  since 
more  detail  can  be  quickly  retrieved. 

With  retrieval  of  data  on-line,  updating  would  most 
likely  be  on-line.   The  nurse  of  a  particular  doctor  is  more 
familiar  with  the  terminology  of  that  doctor  than  any  central 
updating  service  would  be.   Also,  the  thought  of  200-400  doctors 
sending  incomplete  forms  to  the  central  updating  services  makes 
it  economically  plausible  that  the  updating  should  be  done  at 
each  doctor's  office.   This  also  avoids  double  bookkeeping. 
Having  the  nurse  do  the  updating  requires  CMHDB  to  contain  suf- 
ficient safeguards  to  avoid  accidental  (or  purposeful)  removal 
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or  changing  of  the  wrong  information.   Posting  the  current 
date  and  other  miscellaneous  bookkeeping  could  be  done  auto- 
matically by  CMHDB. 

Some  doctors  or  hospitals  may  want  to  use  "Mumps"  while 
others  may  establish  their  own  language  to  cope  with  their  par- 
ticular terminology  or  special  needs.   Because  of  this,  it  is 
expected  that  each  user  could  have  his  own  customized  inter- 
face.  It  will  be  up  to  the  doctor  or  hospital  to  implement 
the  interface.   For  further  information  on  "Mumps",  see  [25]. 
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CHAPTER  3 
DATA  BASE  ARCHITECTURE 

3.1   Legal  Impediments 

The  changes  required  in  the  law  to  allow  CMHDB  to  be 
efficient  and  effective  poses  a  problem  almost  as  immense  as 
the  development  of  CMHDB.   There  is  no  distinct  body  of  law 
to  be  attacked.   The  government  makes  laws  in  response  to  in- 
fluences, post  de  facto.   As  the  law  is  presently  stated,  the 
creation  of  an  automated  system  is  precluded.   See  in  partic- 
ular [21  and  64] . 

Many  states,  such  as  California  and  Kansas,  have  regu- 
lations that  allow  automation  of  medical  records  after  the  orig- 
inal records  have  been  manually  created.   In  Maryland,  as  in 
other  states,  medical  records  are  required  to  be  manually  cre- 
ated, i.e.,  legibly  written  by  pen.   Laws  of  this  nature  must 
be  revised  to  allow  efficient  use  of  automation. 

Regulations  covering  the  contents  of  medical  records 
vary  from  broad  descriptive  statements  in  Arizona,  Iowa,  and 
Ohio  to  Michigan's  regulations  which  contain  specific  itemiza- 
tion of  information  to  be  included  in  the  records.   Generally, 
the  medical  record  principles,  standards,  and  interpretations 
promulgated  by  the  Joint  Commission  on  Accreditation  of  Hospi- 
tals meet  the  various  state  regulations.   State  courts  have 
used  them  as  evidence  of  the  standard  of  care  in  negligence 
cases.   Hence,  any  automated  medical  record  system  would  do 
well  to  abide  by  these  standards. 
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The  Joint  Commission  with  the  interpretations  under 
Standard  II  requires  all  medical  records  to  contain: 

1.  Identification  data  and  consent  forms, 

2.  History  of  the  patient, 

3.  Report  of  the  physical  examination, 

4.  Diagnostic  and  therapeutic  orders, 

5.  Observations, 

6.  Reports  of  actions  and  findings,  and 

7.  Conclusions. 

The  patient  medical  records,  usually  the  most  detailed, 
should  include:   patient's  name,  address,  next  of  kin,  and  other 
pertinent  data  for  identification  and  consents  as  deemed  neces- 
sary by  the  hospital's  administration  and  the  medical  staff. 

The  history  of  the  patient  should  incorporate  the  chief 
complaints,  details  of  past  illness,  inventory  of  systems,  past 
history,  social  history,  and  family  history.   This  history 
should  be  as  unbiased  and  concise  as  humanly  possible. 

The  report  of  the  physical  examination  should  contain 
all  relevant  findings  resulting  from  an  assessment  of  all  the 
systems  of  the  body.   If  a  physical  examination  has  been  con- 
ducted recently,  then  only  new  information  need  be  recorded 
with  the  understanding  that  no  other  information  has  changed 
since  then. 

Diagnostic  and  therapeutic  orders  written  by  authorized 
house  staff  members  and  other  individuals  who  have  assigned 
practice  privileges,  telephone  orders  written  by  licensed 
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nurses,  and  diet  orders  should  be  contained  in  the  patient 
record. 

Observation  reports  should  include  progress  notes  by 
the  medical  staff  and  house  staff,  consultation  reports,  nur- 
ses' notes,  and  entries  by  allied  health  personnel.   Consulta- 
tion reports  should  contain  a  written  opinion  by  the  consul- 
tant.  Progress  notes  by  the  medical  staff  should  give  a  chron- 
ological report  of  pertinent  facts  concerning  the  patient's 
recovery  and  should  be  sufficient  to  describe  the  changes  in 
each  of  the  patient's  conditions  and  the  results  of  the  treat- 
ment.  Nurses'  notes  and  entries  by  allied  health  personnel 
should  contain  only  meaningful  information.   Opinions  requir- 
ing medical  judgment  should  be  authenticated  only  by  authorized 
house  staff  members  and  those  persons  who  have  been  assigned 
practice  privileges. 

Reports  of  actions  and  findings  should  include  such 
items  as  reports  of  pathology  and  clinical  laboratory  examina- 
tions, radiology  examinations,  medical  and  surgical  treatment, 
and  any  other  diagnostic  or  therapeutic  procedures.   All  diag- 
nostic and  therapeutic  procedures  should  be  recorded  and  authen- 
ticated in  the  medical  record  and  may  include  any  reports  from 
out-of-hospital  facilities.   All  treatment  procedures  performed 
must  be  documented  in  the  medical  record.   The  surgeon  should 
record  and  sign  a  preoperative  diagnosis  prior  to  surgery. 
Operative  notes,  prepared  after  surgery,  should  contain  a  de- 
scription of  the  findings,  the  techniques  used,  the  tissue  re- 
moved or  altered,  and  post-operative  diagnosis. 
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The  conclusion  includes  provisional  diagnosis,  primary 
and  secondary  final  diagnosis,  clinical  resume  and  necropsy 
reports.   The  provisional  diagnosis  should  reflect  the  respon- 
sible practioner's  evaluation  of  the  patient's  condition  at  the 
time  of  admission.   All  relevant  discharge  diagnoses  should  be 
recorded,  using  the  terminology  of  a  recognized  system  of 
disease  nomenclature.   The  clinical  resume  should  summarize 
the  significant  findings  and  events  of  the  patient's  hospital- 
ization, his  condition  on  discharge,  and  the  recommendations 
and  arrangements  for  future  care.   Where  a  necropsy  is  performed, 
provisional  and  anatomic  diagnosis  should  be  recorded  on  the 
medical  record  within  72  hours,  where  feasible,  and  the  complete 
protocol  should  be  made  part  of  the  record  within  three  months. 

A  copy  of  the  clinical  resume  is  required  to  be  sent 
to  the  medical  practitioner  or  clinic  responsible  for  subsequent 
care  of  the  patient.   This  requirement  would  be  implicitly  met 
by  CMHDB,  since  the  resume  is  available  to  anyone  who  needs  it 
once  the  clinical  resume  is  entered. 

Some  comments  should  be  made  here  concerning  certain 
key  words  and  phrases.   The  phrase  "entries  by  allied  health 
personnel,"  recognizes  that  persons  other  than  medical  or  den- 
tal practitioners  and  licensed  nurses  may  write  entries.   This 
is  important  because  specialized  personnel  may  be  needed  for 
data  entry  into  CMHDB. 

The  words,  "pertinent,"  "relevant,"  "meaningful"  and 
"necessary,"  need  to  be  defined  to  form  uniform  and  standard 
records.  It  is  generally  accepted  that  whether  or  not  auto- 
mation is  implemented  medical  records  need  to  be  reorganized. 
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Medical  records  at  this  time  contain  much  useless  information 
and  are  often  missing  useful  information.   Automation  of  medi- 
cal records  may  prove  to  be  the  catalyst  for  this  reorganization. 

Then  there  are  the  key  words  "signature"  and  "authen- 
tication."  The  Joint  Commission  of  Accreditation  of  Hospitals 
has  been  farsighted  in  recognizing  the  potential  application  of 
computer  technology  to  medical  records.   This  is  seen  in  the 
Joint  Commission  definition  of  "authenticated":   To  prove 
authorship,  for  example,  written  signature,  identifiable  ini- 
tials or  computer  key.   Many  states  have  regulations  requiring 
handwritten  signatures  which  will  have  to  be  modified  before 
automated  medical  records  can  be  effective. 

Hospital  medical  records  are  retained  anywhere  from  7 
to  25  years,  depending  on  the  state  regulation.   The  American 
Hospital  Association  recommends  15  years.   The  Joint  Commission 
interpretation  states,  "The  length  of  time  that  records  are  to 
be  kept  is  dependent  upon  the  length  of  time  that  they  may  be 
needed  for  continuing  patient  care  and  for  legal,  research,  or 
educational  purposes."   In  any  case,  an  automated  medical  re- 
cord system  would  have  to  retain  records  for  an  indefinitely 
long  period,  which  can  be  treated  as  permanent. 

A  more  detailed  discussion  of  the  law  and  automated 
medical  records  can  be  found  in  [64] . 

3.2   Security 

Access  control  to  the  data  base  has  important  implica- 
tions in  the  content  and  structure  of  the  data  base.   The 
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software  security  features  will,  of  course,  work  in  conjunc- 
tion with  hardware  features.   Nevertheless,  software  safety 
techniques  have  a  dramatic  effect  on  the  data  base.   First  of 
all,  a  list  of  eligible  users  must  be  maintained  in  a  high 
level  of  the  memory  hierarchy.   Accompanying  every  request 
must  be  a  positive  identification  of  the  user.   Sufficient 
identification  information  to  recognize  the  user  to  a  high 
confidence  level  plus  the  degree  of  access  freedom  the  user 
has  is    information    that  will  be  frequently  used. 

It  is  possible  that  identification  could  be  as  simple 
as  using  a  bank  cash  card  where  the  user  would  enter  a  machine 
readable  card  and  separately  enter  through  a  console  a  code. 
Identification  could  be  further  verified  by  having  the  computer 
asking  suspicious  users  or  randomly  selected  users  such  ques- 
tions as  birthdate,  address,  or  questions  from  the  user's  medi- 
cal file. 

Access  control  is  simplified  if  the  data  is  struc- 
tured in  a  modular  fashion.   This  is  so  users  restricted  to  a 
certain  type  of  information  can  be  easily  given  just  that  in- 
formation.  For  instance,  an  orthodontist  should  not  be  allowed 
and  it  is  unlikely  that  he  would  want  information  concerning 
the  obstetrics  of  his  patient.   However,  serious  problems  do 
arise  as  to  whom  is  allowed  what  information.   It  would  be  dif- 
ficult indeed  to  provide  mutually  exclusive  data  for  the  obste- 
trician and  the  orthopedist.   This  would  imply  that  the  data 
base  should  be  organized  into  small  blocks  of  data  and  that  for 
each  user  there  should  be  a  list  of  those  data  blocks  to  which 
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the  user  has  access.   A  solution  to  this  problem  is  achieved 
by  organizing  the  data  base  on  a  problem-oriented  basis.   The 
speciality  of  a  doctor  is  defined  by  the  problems  he  is  trained 
to  cure.   A  problem-oriented  organization  allows  the  doctor 
the  information  he  needs  while  at  the  same  time  he  can  be  re- 
stricted to  just  that  information.   Most  hospitals  presently 
organize  their  patient  files  by  hospital  stay,  but  each  hospi- 
tal stay  usually  has  a  list  of  problems  in  Hospital-International 
Classification  of  Diseases-Adapted  (H-ICD-A)  codes  on  the  dis- 
charge summary  sheet. 

Most  problem  coding  is  either  infeasible  or  at  best  in- 
efficient for  computer  use.   For  example,  Current  Medical  In- 
formation £  Terminology  (CMIT)  codes  spleen  infraction  as 
05-3723  and  myocardium  infraction  acute  as  04-1921,  and  a  new 
code  for  each  infraction.   This  makes  statistical  searches  dif- 
ficult, to  say  the  least,  and  lookup  tables  quite  large. 
H-ICD-A  and  International  Classification  of  Diseases-Adapted 
(ICD-A)  are  modifications  of  International  Classification  of 
Diseases  (ICD)  which  was  developed  100  years  ago  to  record 
causes  of  death,  and  has  a  structure  unsuitable  for  the  computer. 

In  1965,  the  College  of  American  Pathologists  published 
SNOP ,  Systemized  Nomenclature  of  Pathology.   It  is  presently 
being  extended  to  become  either  the  Lexicon  of  Medical  Prac- 
tice for  Computer  or  Systematized  Nomenclature  of  Medicine 
(SNOMed) .   SNOMed  codes  will  contain  five  fields  as  follows: 

1.   Topography  -  anatomic  sites  of  disease, 
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2.  Morphology  -  names  of  visually  apparent  altera- 

tions of  the  cell,  tissue  or  organ  structure, 

3.  Etiology  -  a  classification  of  causes  of  diseases 

and  injuries , 

4.  Function  -  the  terms  for  disturbances  of  physio- 

logic function  as  in  signs  and  symptoms, 

5 .  Therapy  and  Diagnostic  Procedures  and  Miscellan- 

eous Hospital  Functions  -  the  names  of  forms  of 
therapy  and  diagnostic  procedures. 

The  first  four  fields  are  the  same  as  SNOP  and  the  fifth  could 

be  a  modified  version  of  the  Current  Procedural  Terminology  of 

the  AMA. 

The  topography  field  consists  of  two  parts,  a  site  num- 
ber and  a  sub-site  number.  There  are  140  sites  and  a  variable 
number  of  sub-sites,  depending  on  the  particular  site.  All  36 
parts  of  the  lung,  for  example,  would  be  preceded  by  the  site 
code  28.  Greater  detail  will  be  required  in  the  topography  of 
SNOMed  to  satisfy  the  wide  variety  of  specialists  in  the  medi- 
cal field. 

The  other  three  fields  of  SNOP  have  the  same  two  part 
structure.   The  divisions  of  Morphology  include: 

1.  Traumatic  Abnormalities, 

2.  Congenital  Malformations,  Absences  and  Deform- 

ities , 

3.  Mechanical  Abnormalities, 

4.  Inflammations  and  Repair, 

5.  Degenerations,  Neerosis  and  Depositions, 

6.  Fine  Structure  and  Cytologic  Alterations, 

7.  Growth  Alterations, 

8. and  9.   Neoplasms  and  Miscellaneous  Conditions. 
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In  Etiology  the  sections  are: 

1.  Bacteria, 

2.  Rickettsiae, 

3.  Viruses, 

4.  Other  Pathogenic  Organisms, 

5.  Chemicals, 

6.  Reserved  for  Expansion, 

7.  and  8.   Drugs, 

9.   Physical  Agents  of  Injury. 
It  is  hoped  most  microbiologic  parts  of  this  field  will  be 
contained  in  SNOMed . 

The  field  of  Function  has: 

1.  Disorders  of  Elements,  Ions,  Simple  Compounds, 

and  Certain  Metalloproteins , 

2.  Metabolic  and  Nutritional  Disorders, 

3.  Enzyme  Disorders, 

4.  Endoerine  Disorders, 

5.  Blood  Coagulation  Disorders, 

6.  Immune  Responses  and  Hypersensitivity  Reactions, 

7.  Cardiovascular,  Respiratory  and  Neuromuscular 

Disorders , 

8.  Mental,  Psychic,  and  Personality  Disorders, 

9.  Miscellaneous  Functional  Disorders. 

There  will  be  many  additions  to  this  field  in  SNOMed  (more  con- 
cerning SNOMed  can  be  found  in  [69]). 

With  the  code  being  stored  in  the  data  base,  a  central 
dictionary  can  be  stored  to  translate  the  code  into  preferred 
terms  and  synonyms  or  just  the  preferred  term  with  the 
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translation  of  preferred  term  into  the  local  synonyms  being 
done  at  the  terminal.   Reverse  translation  can  be  done  sim- 
ilarly.  In  many  cases,  it  may  be  quicker  for  the  doctor  or 
his  nurse  to  deal  directly  with  the  SNOMed  code.   As  an  example, 
a  visual  aid  for  SNOP  has  been  tested.   Most  terms  are  arranged 
according  to  topography.   Their  code  numbers  can  be  located  in 
seconds  by  lifting  the  page  to  the  proper  site  to  select  from 
the  alphabetically  arranged  diagnoses.   Such  visual  aids  could 
be  prepared  for  each  of  the  different  fields  in  medicine  [69] . 

Using  SNOMed  for  coding  diagnoses  provides  quick  coding 
of  the  diagnoses,  easy  manipulation  and  retrieval  by  computer, 
and  most  important  of  all  a  means  of  restricting  the  flow  in 
information.   Using  this  coding,  users  can  be  restricted  in  the 
kind  of  information  they  receive  by  storing  a  set  of  codes  each 
user  can  request.   Treating  the  coding  as  a  five  dimensional 
space,  this  restricting  set  would  range  from  a  list  of  points 
to  a  cross  product  of  intervals  on  each  axis.   SNOMed  also 
allows  the  user  more  freedom  to  request  very  specifically  which 
disease  he  wishes  information  on  by  entering  one  number  for  one 
field  to  find  all  diseases  with  that  characteristic  in  the 
patient's  history.   This  also  allows  statisticians  a  wide  lat- 
itude.  Searches  for  certain  combinations  are  much  easier  to 
locate. 

Besides  restricting  the  information  requested  to  that 
information  relevant  to  the  user,  a  user  can  be  restricted  to 
read-only  or  write-only.  A  private  doctor  and  his  nurse,  for 
example,  would  have  access  only  to  those  records  relevant  to 
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his  practice  and  then  only  through  his  terminal.   It  is  pos- 
sible that  the  doctor,  owing  to  his  reputation  for  legibility 
and  completeness,  may  be  allowed  read-only  access  while  the 
nurse  might  only  have  write-only  access. 

3.3   Directories 

After  solving  the  legal  problems  and  deciding  on  se- 
curity information,  medical  codes,  and  data  base  contents,  the 
architecture  of  the  data  base  can  be  discussed  in  depth.   The 
first  structure  encountered  are  the  directories. 

Two  main  directories  are  needed  in  the  data  base,  one 
for  user  identification  and  one  for  patient  sub-directories. 
The  user  directory  first  must  contain  the  user  identification 
number  and  if  a  pass  card  system  is  used  the  code  is  needed. 
It  is  possible  that  these  two  numbers  could  be  replaced  by  a 
digitized  voice  print  or  finger  print,  but  these  would  require 
much  more  storage.   Also  needed  is  a  list  of  terminals  the 
user  is  permitted  or  expected  to  use.   Should  user  identifica- 
tion number,  code  and  terminal  identification  not  match  those 
in  the  directory,  the  computer  may  wish  to  question  the  user 
further  to  confirm  identification  or  report  the  attempted  mis- 
use.  For  this  the  user's  data  base  or  patient  identification 
number  is  needed.   The  user's  patient  file  would  contain  his 
name,  occupation  and  address  and  this  information  should  not 
be  duplicated  in  the  user  directory.   Once  the  user  has 
achieved  clearance,  his  request  must  be  checked  to  see  if  it 
is  within  the  restricting  set;  that  is,  the  information  re- 
quested is  relevant  to  his  specialty.   Whether  the  user  has 
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read-only,  write-only,  or  read  and  write  access  must  also  be 
determined.   This  user  identification  directory  does  not  read- 
ily lend  itself  to  compaction.   The  following  illustrates  the 
suggested  contents  for  the  directory  with  their  approximate 
size  in  core. 

User  identification  number  2  bytes 

Code  2  bytes 

Data  base  number  3  bytes 

Flags  (count  of  terminal 
numbers  and  size  of 
restriction  set)  2  bytes 

Read-write  Access  2  bits 

Terminal  numbers  (variable)  1  byte  each 

Restriction  set  (variable)  10  byte  minimum 

Minimum  number  of  bytes 

per  user  20  bytes 

Read-write  access  and  terminal  numbers  might  be  combined  into 
one  number  indicating  a  set  of  terminals  the  user  can  use  and 
his  read-write  access.   The  restriction  set  will  need  overhead 
storage  to  indicate  the  number  of  subsets  and  whether  each  sub- 
set consists  of  a  single  point  or  a  set  of  points  (Figure  1) . 

If  one  allows  for  the  possibility  of  500  users,  the 
user  directory  would  require  10-15K  bytes.   This  size  direc- 
tory could  easily  be  contained  in  core  on  a  medium-large  com- 
puter.  It  is  not  expected  that  there  will  be  a  very  dynamic 
turnover  of  users  or  very  many  changes  in  user  access  rights. 
Probably  the  most  that  need  be  expected  is  a  weekly  update. 
Because  of  this  relative  stability  and  the  core  contained  size, 
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User  ID# 

Code 

Patient  ID# 

a 

b 

c 

d 

e 

Restriction  Set 

a)  Number  of  terminals  (4  bits) 

b)  Size  of  restriction  set  (10  bits) 

c)  User  read-write  access  rights  (2  bits) 

d)  6  e)  Terminal  identification  numbers 

(1  byte  each) 


Figure  1.   User  directory  element. 
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a  rather  fixed  structure  allowing  rapid  access  can  be  used. 
Some  permutations  of  the  access  code  can  be  used  for  a  simple 
table  lookup  of  the  particular  user  entry  address.   The  user 
entry  can  then  be  accessed  with  this  address  for  verifying 
identification . 

Once  clearance  for  the  user  and  his  request  has  been 
accomplished,  the  data  base  is  ready  to  be  entered.   If  the 
request  is  for  the  entering  of  new  information  or  a  new  pa- 
tient, then  it  is  assumed  the  computer  will  automatically  store 
the  information  and  make  all  the  needed  entries  in  the  appro- 
priate tables.   The  "appropriate  tables"  just  referred  to  will 
be  discussed  as  viewed  with  respect  to  requests  for  information 
retrieval.   Every  request  will  contain  a  patient  identification 
number  and  at  least  one  SNOP  number.   Other  information  in  the 
request  might  include  dates  indicating  how  recent  or  old  the 
information  should  be,  combination  of  SNOP  numbers  indicating 
a  search  for  complications  of  a  disease  or  request  for  specific 
test  results. 

Location  of  the  patient  directory  is  the  first  problem 
in  answering  a  request.   The  patient  identification  number  will 
be  used  to  locate  a  patient  directory,  since  names  are  not 
unique  and  phonetically  similar  names  are  easily  misspelled. 
Once  the  particular  directory  is  located,  name,  address,  and 
other  identification  information  can  be  sent  back  to  the  ter- 
minal for  verification  of  the  patient  identification  while  the 
requested  information  is  being  retrieved.   If  the  data  base  is 
designed  to  handle  100,000  patient  histories,  any  table  lookup 
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runs  into  storage  problems.   Using  a  transformation  of  the 
patient  identification  number  to  address  the  table  and  allow- 
ing three  bytes  for  the  directory  address  and  directory  length, 
300K  bytes  of  storage  are  needed  for  the  table.   Since  this 
table  is  used  with  every  request,  small  access  times  are  needed. 
To  avoid  frequently  retrieving  sections  of  the  table  from  sec- 
ondary memory,  as  large  a  section  as  possible  should  be  main- 
tained in  primary  storage.   Ideally  the  whole  table  would  be 
in  core.   All  of  which  means  a  large  core  is  required. 

Once  the  particular  directory  address  has  been  retrieved 
from  the  table,  the  patient  directory  can  be  retrieved.   Immed- 
iately upon  retrieval  identification  information  can  be  sent 
for  verification  of  the  patient  number.   The  identification  in- 
formation should  consist  of  name,  current  address,  marital  sta- 
tus, birth  date,  and  physical  description.   The  physical  de- 
scription would  include  height,  weight,  color  of  eyes  and  hair, 
sex,  and  race.   This  is  sufficient  information  for  the  requestor 
to  make  a  positive  identification  on  the  patient  even  if  some  of 
the  information  is  wrong.   By  letting  the  requestor  make  the 
visual  check,  it  saves  the  requestor  from  typing  this  informa- 
tion into  the  computer,  saves  the  computer  from  making  the  match 
and  deciding  if  sufficient  information  matches  to  make  a  positive 
identification,  and  finally  occupies  the  requestor  while  the  com- 
puter retrieves  the  needed  information. 

To  retrieve  the  requested  information,  the  computer  would 
search  a  linked  list  of  SNOMed  codes  in  the  patient  directory. 
The  list  would  include  codes  for  family  history,  personality 
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history,  and  the  social  history,  besides  those  for  the  medical 
history. 

Because  there  are  expected  to  be  as  many  as  100,000 
patient  directories,  storage  conservation  and  data  compaction 
are  of  prime  importance.   Many  data  compaction  techniques  are 
presented  in  the  literature.   The  methods  referred  to  in  the 
following  discussion  are  explained  in  detail  in  the  references 
[45,  55,  and  61].   The  header  information  of  the  patient  direc- 
tories can  be  broken  into  three  fields;  name,  address,  and  de- 
scription.  The  name  field  would  have  the  format:   last,  first, 
middle  initial.   As  can  be  seen,  using  "b"  and  "#"  to  repre- 
sent a  blank  and  end  of  field  respectively,  coding  " ,b"  and 
".#"  as  one  character  each  is  feasible.   Similarly,  in  a  study 
whose  results  are  presented  in  Figure  2,  10  other  pairs  oc- 
curred with  sufficient  frequency  to  warrant  coding  with  a  spe- 
cial character  .   With  the  code  presented  in  Figure  2,  an  average 
of  4.14  bits  were  needed  to  encode  one  character.   If  a  differ- 
ent format  were  used  or  the  whole  middle  name  was  included,  a 
new  frequency  study  would  have  to  be  made.   The  codes  are  con- 
structed such  that  from  the  first  four  bits  of  the  code,  the 
number  of  bits  in  the  code  can  be  determined.   For  example,  all 
seven  bit  codes  and  only  seven  bit  codes  begin  with  "1111." 
Also,  since  the  characters  are  ordered  by  frequency  of  occur- 
rence, it  can  be  concluded  that  four  bit  codes  occur  nearly 
40  per  cent  of  the  time.   Therefore,  40  per  cent  of  the  time  a 
direct  one  step  table  lookup  is  all  that  is  needed  for  the 
translation. 
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The  address  field  usually  has  a  format  similar  to: 
NNN  street  name  St.  (1) 

City,  State  NNNNN  (2) 

where  "N"  represents  a  decimal  digit  between  0  and  9.   Line 
(1)  can  be  coded  with  two  codes,  a  prefix  code  and  a  suffix 
code.   Different  codes  are  needed  because  a  significantly  dif- 
ferent distribution  is  found  in  line  (1)  than  in  the  name  field 
or  in  a  general  English  text.   The  prefix  code  would  be  used 
for  the  sequences  of  numbers  of  ten  followed  by  a  N,  E,  S,  or 
W.   The  suffix  code  would  code  the  rest  using  a  single  charac- 
ter for  such   common   combinations  as  "bst".   Such  codes  are 
presented  in  Figures  3  and  4.   Line  (1)  can  be  coded  on  the 
average  with  3.79  bits  per  character,  while  line  (2)  can  be 
compressed  in  several  different  ways,  depending  on  the  number 
of  cities  involved.   With  very  few  cities  involved  and  one  city 
of  particular  high  frequency,  a  Huffman  code  can  be  used  where 
0  is  assigned  to  the  most  frequent  city-state  combination,  10 
to  the  second  most  frequent,  110  to  the  third,  etc.   With  sev- 
eral cities  a  six  or  seven  bit  code  could  be  used  for  a  table 
lookup.   With  many  cities,  the  states  could  be  numbered  for  a 
table  lookup  and  new  statistical  variable  codes  could  be  devel- 
oped for  the  cities  and  zip  codes. 

The  description  field  would  be  fixed  length.   Marital 
status  can  be  represented  by  two  bits  (single,  married,  separ- 
ated, divorced).   Birth  dates  can  be  coded  in  16  bits  (5  for 
the  day,  4  for  the  month,  and  7  for  the  last  two  digits  of  the 
year).   There  are  still  only  two  sexes  for  1  bit.   Physical 
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Character 

Frequency 

Probability 

Code 

b 

29,500 

.1965 

000 

-A 

24,010 

.1600 

001 

1 

14,693 

.0980 

010 

2 

12,945 

.0863 

0110 

3 

9,196 

.0612 

0111 

• 

9,000 

.0600 

1000 

5 

7 ,  907 

.0527 

1001 

0 

7,639 

.0508 

1010 

4 

7,319 

.0487 

1011 

6 

5,858 

.0397 

11000 

7 

4,607 

.0307 

11001 

8 

4,229 

.0282 

11010 

N 

4,000 

.0267 

11011 

9 

3,534 

.0235 

11100 

W 

1,500 

.0100 

11101 

S 

1,500 

.0100 

11110 

E 

1,500 

.0100 

11111 

Totals   148,937 


,9930 


Figure  3.   Prefix  codes  used  in  address  fields. 
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Character 

Frequency 

Probability     Code 

E 

18,824 

.0858 

0000 

R 

15,931 

.0726 

0001 

T 

15,866 

.0723 

0010 

N 

14,489 

.0660 

0011 

A 

13,633 

.0622 

0100 

bST.# 

12,500 

.0570 

0101 

b 

12,220 

.0557 

0110 

0 

11,898 

.0542 

0111 

S 

11,196 

.0510 

1000 

L 

9,87  5 

.0449 

10010 

# 

8,510 

.0387 

10011 

D 

8,416 

.0383 

10100 

^ 

.0360 

10101 

I 

7,748 

.0352 

10110 

H 

7,397 

.0337 

10111 

C 

5,021 

.0228 

11000 

M 

4,256 

.0194 

11001 

W 

3,727 

.0170 

11010 

G 

3,509 

.0160 

11011 

U 

3,449 

.0157 

111000 

P 

3,278 

.0149 

111001 

B 

3,149 

.0143 

111010 

bAVE.# 

3,000 

.0137 

111011 

K 

2,601 

.0118 

1111000 

• 

2,430 

.0111 

1111001 

Y 

2,354 

.0107 

1111010 

F 

2,235 

.0102 

1111011 

V 

1,702 

.0078 

1111100 

/ 

974 

.0044 

1111101 

0 

800 

.0036 

1111110 

1 

800 

.0036 

1111111 

2 

800 

.0037\ 
.0036 1 

0000 

3 

800 

0001 

4 

800 

.0036 

0010 

5 

800 

.0037 

0011 

6 

800 

.0036 

1        0100 

\       0101 

Ya     0110 

7 

800 

.0036 

8 

800 

.0037 

9 

800 

.0036 

/?     0111 

J 

441 

.0020 

/        1000 

Z 

410 

.00.19 

10010 

— 

257 

.0012 

\       10011 

X 

249 

.0011 

j       10100 

Q 

121 

.0005 

\       10101 

<§> 

42 

.0002 

/       10110 

& 

00 

.OOOOy 

10111 

Totals 

21^,708 

1.0006 

Figure  4.   Suffix  codes — used  for  address  fields 
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description  can  be  coded  as  follows: 

1.  Color  of  hair  (black,  brown,  blonde, 

grey,  others)  3  bits 

2.  Color  of  eyes  (blue,  brown,  others)     2  bits 

3.  Race  (Caucasian,  Black,  Chicano , 

Oriental,  others)  3  bits 

4.  Height  (0-128  inches)  7  bits 

(0-256  centimeters)  8  bits 

5.  Weight  (0-512  pounds)  9  bits 

(0.0-204.8  kg.)  11  bits 

Using  inches  and  pounds  the  description  field  is  43 
bits.   Assuming  80  per  cent  of  the  time  that  the  name  field  is 
less  than  or  equal  to  twenty  characters,  line  (1)  is  then  less 
than  or  equal  to  twenty-five  characters  and  line  (2)  can  be 
represented  by  a  seven  bit  code.   Thus,  to  encode  line  (1) , 
line  (2),  and  the  description  field,  a  thirty  byte  record  can 
be  used  with  a  high  confidence  level  that  a  trailer  will  not  be 
needed.   If  a  trailer  of  an  additional  ten  bytes  is  needed  for 
the  overflow,  the  last  bit  of  the  record  can  be  used  as  a  flag. 

Once  the  header  record  has  been  retrieved,  translated, 
and  sent,  the  computer  can  search  for  the  SNOMed  codes  requested 
Each  patient  directory  would  hopefully  contain  at  least  three 
codes,  those  for  the  family,  social,  and  personal  histories.   It 
is  not  expected,  though,  that  there  will  be  enough  codes,  on  the 
average,  to  warrant  a  complex  tree  structure.   A  simple  linear 
linked  list  with  the  codes  in  numerical  order  is  expected  to 
suffice.   The  five  field  SNOMed  codes  are  ten  bytes  long.   Any 
attempt  to  organize  the  codes  would  result  in  a  high  overhead 
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Name  field 


Address 


I 


pref  i 


3 


Address  suffix 


Pty 


empty 


Description  field 


a)  City-zipcode  table  address     (6  bits) 

b)  State  table  address  (6  bits) 

c)  Trailer  flag  (1  bit) 


Note:   a  double  vertical  line  represents  an  end 
of  field  character. 


Figure  5.   A  patient  directory  information  header. 
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in  terms  of  storage,  maintenance  time,  and  search  time.   For 
instance,  if  each  field  is  linked  in  a  numerically  ordered 
list,  one  additional  byte  for  each  field  for  the  link  address 
would  be  needed.   Five  more  bytes  for  each  of  20  codes  for 
100,000  patients  is  10M  bytes  more  for  the  patient  directories 
and  five  linked  lists  to  be  altered  each  time  a  new  code  is 
entered.   Each  element  of  the  list  would  contain  a  ten  byte 
code,  one  byte  for  the  number  of  references  and  five  bytes 
for  each  reference  consisting  of  two  bytes  for  date  and  three 
bytes  for  address.   Since  two  or  more  SNOMed  codes  could  refer- 
ence the  same  address,  with  some  coding  a  reference  might  just 
point  to  another  reference  that  has  the  same  date  and  address 
at  a  savings  of  four  bytes.   If  the  list  were  ordered  by  the 
topography  field,  then  a  request  for  any  history  of  inflamma- 
tions within  the  last  year  would  search  every  Morphology  field 
in  the  list  for  code  4  with  a  reference  not  older  than  one  year. 
Should  the  list  become  very  long,  time  could  be  saved  by  list- 
ing the  occurrences  of  the  major  divisions  of  the  five  fields 
immediately  following  the  header.   There  would  be  one  list  of 
divisions  and  the  addresses  of  their  occurrences  for  each  field. 
With  at  least  30  bytes  per  header  and  16  bytes  per  list  element, 
100,000   directories  would  probably  occupy  25M  to  50M  bytes,  or 
about  one  full  disk  (Figure  5) . 

3.4   Files 

It  is  hoped  that  automated  records  will  spur  reorganiza- 
tion of  medical  records  with  intent  to  save  useful  and  only  use- 
ful information.   Man-machine  interaction  will  play  an  important 
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role  in  this  organization.   However,  in  one  experiment  with 
nurses  and  automated  records,  nurses  entered  four  times  as 
many  notes  as  normal  which  had  half  the  normal  useful  content. 

Besides  deciding  what  is  useful  data,  standardization 
is  needed.   As  can  be  seen  in  the  history  or  physical  examina- 
tion form  from  Mercy  Hospital  in  Urbana,  Illinois  (see  Appendix), 
the  doctor  is  allowed  a  rather  free  hand  in  filling  out  the  form. 
Certainly  there  are  questions  that  will  always  be  left  to  the 
discretion  of  the  doctor,  but  there  are  several  that  can  be 
answered  with  a  yes,  no,  (a),  (b) ,  (c) ,  or  98.6  in  "check-off" 
list  fashion.   In  addition,  standard  questions  should  be  listed 
so  that  the  doctor  does  not  forget  anything  and  the  record  is 
complete. 

University  of  Illinois'  McKinley  Hospital  has  an  auto- 
mated history  that  is  given  patients  periodically.   The  history 
contains  100-200  questions  such  as  "do  you  smoke?"  and  if  the 
answer  is  yes,  "how  many  packs  a  day?".   The  answers  are  stored 
in  192  words,  not  compacted.   When  uniform  standard  forms  are 
used,  a  "yes"  answer  can  be  stored  with  one  bit  instead  of  hav- 
ing to  store  an  arbitrary  question  and  answer  that  would  consume 
several  bytes.   Standardization  has  other  positive  side  effects 
such  as  making  it  more  feasible  to  use  para-medics  for  standard 
questioning  and  having  the  doctor  add  any  free  text  notes  he 
feels  are  necessary,  thereby  freeing  the  doctor  from  much  of  the 
routine  for  more  important  things . 

Free  text  can  be  compacted  about  35  per  cent,  depending 
on  the  character  distribution.   The  use  of  variable  length 
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character  codes  becomes  unwieldly  when  an  unrestricted  charac- 
ter code  such  as  the  88  EBCDIC  character  set  is  used.   If  it 
is  found  in  a  study  of  medical  free  text  that  the  whole  char- 
acter set  is  not  needed,  then  variable  length  character  codes 
could  be  considered.   Other  factors  affecting  the  decision  of 
whether  or  not  to  use  variable  length  code  are  character  fre- 
quency distribution,  frequency  of  certain  combinations  of 
characters,  and  the  possible  use  of  a  certain  subset  of  char- 
acters on  a  particular  form  allowing  for  the  use  of  different 
compaction  codes  in  different  places. 

One  way  to  compact  an  unrestricted  character  set  is  to 
use  the  free  codes  for  pairs  of  characters.   For  example,  only 
88  of  a  possible  256  EBCDIC  codes  are  used,  leaving  168  codes 
for  pairs  of  characters.   The  following  method  employing  this 
idea  has  been  suggested  as  being  efficient  in  compaction  and 
expansion  times.   EBCDIC  spreads  its  88  codes  over  the  256 
possible  values.   The  compaction  code  compresses  the  88  codes 
into  the  first  88  values  (i.e.,  A  is  1,  B  is  2,  etc.).   Then 
master  and  combining  characters  are  chosen  such  that  the  number 
of  master  characters  times  the  number  of  combining  characters 
is  less  than  or  equal  to  168  and  such  that  the  frequency  of 
the  combined  pairs  is  maximized  for  optimal  compaction.   In 
Figure  6,  eight  master  characters  were  chosen.   Of  the  eight 
letters  chosen,  six  occurred  most  frequently  while  I  and  U 
were  chosen  for  their  key  position  in  syllables.   For  combining 
characters  the  21  most  frequent  characters  were  chosen. 
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The  following  is  the  algorithm  for  compaction. 

Step  1.   Translate  EBCDIC  stream  into  compressed 
code. 

Step  2.   Check  for  master  characters. 

If  it  is  a  master  character,  go  to  step  3. 

If  it  is  not  a  master  character,  store 
as  is  and  go  to  step  2  for  next  char- 
acter . 

Step  3.   Check  next  character  for  combining  char- 
acter. 
If  it  is  a  combining  character,  go  to 

step  4 . 
If  it  is  not  a  combining  character, 

store  both  as  is  and  go  to  step  2 

for  next  character. 

Step  4..  Add  base  value  of  master  character  to 
combining  character  and  store. 
Go  to  step  2  for  next  character. 

For  expansion,  a  character  is  comparable  to  58  hexadecimal.   If 
the  character  is  less  than  58,  then  a  table  lookup  retrieves 
one  EBCDIC  character.   If  the  character  is  greater  than  or  equal 
to  58,  then  the  character  is  multiplied  by  two  to  retrieve  two 
EBCDIC  characters  from  the  table.   On  a  IBM  360/40  compaction 
took  73  msec  per  1000  characters,  while  expansion  took  65  msec, 
per  1000  characters  of  output  stream. 

In  a  discussion  with  a  nurse  in  charge  of  hospital  re- 
cords, it  was  found  that  the  average  patient  folder  contained 
about  20  pages.   Most  forms  the  doctor  had  scrawled  on  were 
typed  before  being  put  into  the  patient  folder.   This  indicates 
that  since  most  doctors  restrain  themselves  from  writing  very 
much  and  most  doctors  do  not  write  as  small  as  typing,  and  the 
forms  contain  sufficient  space,  those  forms  that  contain  text 
contain  only  about  250  words.   As  can  be  seen  in  the  medical 
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chart  (Figure  7) ,  about  one-third  of  the  forms  are  mostly 
free  text.   At  an  average  of  5  characters  per  word,  the  hospi- 
tal file  would  contain  10,000  characters  of  free  text  and  5,000 
characters  in  highly  compressable  information  before  compaction. 
After  compaction  this  would  reduce  to  6,500  bytes  of  free  text 
and  1,500  of  other  compacted  information.   This  would  indicate 
about  8,000  bytes  for  a  hospital  file  of  a  single  patient.   This 
file  includes  more  than  one  hospital  stay  by  the  patient.   For 
the  purpose  of  the  data  base,  each  hospital  stay  would  have  to 
be  stored  separately  so  that  the  SNOMed  codes  associated  with 
each  visit  can  address  only  that  visit.   When  one  considers  that 
Mercy  is  only  one  of  three  hospitals  serving  the  patient  in  the 
Champaign-Urbana  area,  and  that  Mercy  serves  9,000  patients  a 
year,  most  of  the  100,000  patients  will  visit  the  hospital  at 
one  time  or  another.   Even  if  only  50,000  patients  ever  visit 
the  hospital,  that  would  require  400M  bytes  just  to  store  the 
hospital  files. 

Quite  a  few  complex  problems  occur  in  compacting  informa- 
tion in  a  hospital  file  as  is  indicated  by  storage  of  test  re- 
sults.  Mercy  Hospital,  which  has  no  real  specialty,  is  capable 
of  giving  243  different  tests,  although  27  of  these  account  for 
85  per  cent  of  those  actually  given.   The  average  patient  re- 
ceives about  13  tests,  one  of  which  is  usually  a  SMA  12/60, 
which  is  12  tests  in  one.   With  so  few  results  (24,  one  for  each 
test  plus  12  for  the  SMA  12/60)  for  each  patient  and  the  fact 
that  a  patient  can  be  given  the  same  test  more  than  once,  it 
appears  more  efficient  to  just  allow  two  bytes  per  test  result, 
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1.  Discharge  Summary  Sheet 

2.  Admitting  Notice 

3 .  Emergency  Room  Record 

4 .  History 

5.  Physical  Examination 

6 .  Consultation 

7.  Laboratory  Sheets  (Date  order) 

Authorization  for  Blood  Transfusions 
Diabetic  Sheet 

8.  X-ray  Reports  (Date  order) 

9.  Electrocardiograms  (Date  order) 

10.  Electroencephalograms  (Date  order) 

11.  Physical  Therapy  Reports 

12.  Social  Service  Reports 

13.  Inhalation  Therapy  Reports 

14.  Doctors  Orders  and  Progress  Notes  (Date  order) 

15.  Graphic  Charts 

16.  Medication  Sheets 

17.  Intake  and  Output 

18.  Vital  Signs  (Date  order) 

19.  Recertif ications  for  Medicare 

20.  Release  for  Information  Forms 

21.  Admission  Check  Off  List 

22.  Nurses  Notes  (In  Date  order) 

23.  Death  Certificate 

24.  Autopsy  Report 

Figure  7.   Medical  chart. 
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1.  Discharge  Summary  Sheet 

2.  Admitting  Notice 

3 .  Emergency  Room  Record 

4.  History 

5.  Physical  Examination 

6 .  Consultation 

7.  Laboratory  Sheets  (Date  order) 

Authorization  for  B.T. 
Diabetic  Sheet 

8.  X-Ray  Reports  (Date  order) 

9.  Electrocardiograms  (Date  order) 

10.  Electroencephalograms  (Date  order) 

11.  Physical  Therapy  Reports 

12.  Social  Service  Reports 

13.  Inhalation  Therapy  Reports 

14.  Authority  to  Operate 

15.  Anesthesia  Record 

16 .  Report  of  Operation 

17.  Tissue  Report 

18.  Recovery  Room  Record 

19.  Doctors  Orders  and  Progress  Notes  (Date  order) 

20.  Graphic  Charts 

21.  Medication  Sheets 

22.  Intake  and  Output 

23.  Vital  Signs 

24.  Recertif ications  for  Medicare 

25.  Release  for  Information 

26.  Admission  Check  Off  List 

27.  Nurses  Notes  (Date  order) 

28.  Death  Certificate 

29.  Autopsy  Report 


Figure  8.   Surgical  chart. 
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1-18.  Same  as  Surgical  Chart 

19.  Cardiac-Pulmonary  Pump  Records 

20.  Physical  Therapy  Records 

21.  Occupational  Therapy  Records 

22.  Inhalation  Therapy  Records 

23.  Social  Service  Records 

24.  Doctors'  Orders  and  Progress  Notes 

25.  Graphic  Charts 

26.  Medication  Sheets 

27.  Intake  and  Output 

28.  Vital  Signs 

29.  Recertif ications  for  Medicare 

30.  Patient's  Transfer 

31.  Admission  Check  Off  List 

32.  Release  of  Information  Form 

33.  Nurses'  Notes  (Date  order) 

34.  Death  Certificate 

35.  Autopsy  Report 

Figure  9.   Cardiac  surgical  chart. 


SAME  AS  A  MEDICAL  CHART 

Reports  for  Voluntary  and  Emergency  Admission 
go  on  back  of  chart. 

Figure  10.   Psychiatric  chart. 
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1.  Discharge  Summary  Sheet 

2 .  Admitting  Notice 

3.  Prenatal  Record 

4.  Release  to  be  in  Delivery  Room 

5.  Labor-Delivery  Record 

6 .  Labor  Summary 

7.  Laboratory  Sheets  (Date  order) 

8.  X-Ray  Reports  (Date  order) 

9.  Doctors'  Orders  and  Progress  Notes 

10.  Graphic  Charts 

11.  Medication  Sheets 

12.  Nurses'  Notes  (Date  order) 

Figure  11.   Obstetrical  chart. 

1.  Discharge  Summary  Sheet 

2.  Admitting  Notice 

3.  Newborn  Physical 

4.  Release  for  Lying-in  Service 

5.  Laboratory  Sheets  (Date  order) 

6.  Report  of  Operation  (Circumcision) 

7.  Doctors'  Orders  and  Progress  Notes 

8.  Nurses'  Notes  (Date  order) 

9.  Birth  Certificate 

Figure  12.   Newborn  chart. 
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one  for  test  identification  and  one  for  the  result.   Too  much 
overhead  would  be  involved  in  trying  to  use  some  combination 
of  fixed  area  for  the  most  frequent  tests  and  a  bit  map  for 
the  rest  to  save  the  one  byte  for  test  identification,  not  to 
mention  the  trouble  with  coding  two  results  for  the  same  test. 
Once  one  byte  has  been  decided  on  for  the  result,  the 
question  arises  as  to  whether  this  provides  sufficient  accuracy 
or  not.   This  question  cannot  be  answered  with  a  "yes,  most  of 
the  time,"  but  must  be  answered,  "yes,  all  of  the  time."   For 
instance,  a  platelet  count  ranges  from  0  to  upward  of  500,000 
with  a  normal  range  for  adults  in  the  area  of  200,000  to  400,000. 
The  accuracy,  though,  is  only  two  significant  decimal  digits. 
Hence,  the  result  can  be  stored  as  a  number  between  0  and  2  56 
and  then  multiplied  by  10,000  on  retrieval.   For  slightly  more 
accuracy  at  the  expense  of  range ,  the  result  can  be  stored  as  a 
multiple  of  5,000.   Some  tests  may  require  three  significant 
decimal  digits.   The  test  for  sodium,  for  example,  is  sensitive 
and  requires  three  decimal  digits  of  accuracy,  but  the  normal 
range  for  this  test  is  136-150  mEq./XL.  which  is  right  in  the 
middle  of  the  one  byte  0-256  range.   Therefore,  the  sodium  test 
will  have  three  decimal  digits  of  significance  with  no  modifica- 
tion to  force  a  fit  into  the  one  byte  range.   In  conclusion,  one 
byte  will  always  allow  two  significant  decimal  digits  and  some- 
times three,  depending  on  the  standard  deviation  and  the  mean  of 
the  result.   Since  the  necessary  accuracy  for  each  test  is  era- 
tic,  a  test  by  test  study  will  have  to  be  made  concerning  accur- 
acy needed  and  available  for  each  test.   The  hospital  file  and 


44 


a 

b 

c   d 

c   d 

c   d 

c   d 

SMA 
ID 

SMA   results 

a 

b 

c   d 

c   d 

c   d 

c 

d 

a 

b 

c   d 

c   d 

c   d 

c   d 

a)  Difference  in  days  between  test  data 

and  admittance  date  (4  bits) 

b)  Number  of  test  given  that  day   (4  bits) 

c)  Test  identification  number      (1  byte) 

d)  Test  result  (1  byte) 


Figure  13.   Laboratory  tests. 
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private  doctors1  file  will  be  the  most  referenced  files  for 
medical  care.   Other  files  of  importance  include  the  family, 
social,  and  personality  histories  and  the  private  doctors' 
reports.   The  family  history  would  contain  history  relating 
to  the  patient  or,  to  say  it  another  way,  family  history  not 
found  in  the  files  of  the  patient's  spouse,  children,  parents, 
brothers,  or  sisters.   It  would  include  the  patient  number  of 
parents,  spouse,  children,  brothers,  or  sisters.   Other  items 
included  would  be  the  history  of  the  income  of  the  patient  and 
his  past  jobs,  homes  (size,  number  of  rooms,  living  conditions), 
types  of  neighborhoods,  access  to  playgrounds,  etc.   Also  a 
list  of  diseases  that  have  occurred  in  the  family  and  are  im- 
portant, such  as  tuberculosis,  allergies,  diabetes,  etc.,  would 
be  included  in  the  file.   Immunization  records  (type,  number, 
age,  and  reactions)  and  serious  illnesses  of  the  patient  would 
be  listed. 

In  the  social  history,  the  patient's  history  of  inter- 
action with  the  public  would  be  listed.   This  would  include  a 
history  of  schools  (public  or  private,  overcrowded,  type  of 
students,  class,  grades,  nursery  school,  special  aptitudes), 
clubs  (political,  professional,  school  or  recreational),  church 
affiliation  and  type  of  home  (country  house,  suburban  house, 
duplex,  apartment  or  high-rise  apartments). 

The  personality  history  would  include  the  patient's  re- 
lations with  others  and  any  history  that  would  affect  these  re- 
lations.  A  history  of  childhood  development  and  nutrition  up 
to  about  the  first  year  would  be  included.   These  records  would 
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be  the  routine  check-ups  given  by  the  doctor.   Also  included 
would  be  habits  (eating,  sleeping,  exercise,  etc.),  attitudes 
toward  school,  and  relations  to  others.   Relations  between  pa- 
tient and  mother,  father,  spouse,  and  children  would  note  any 
shyness,  submissiveness ,  separation,  and  negativism.   Notice 
of  extraordinary  relations  with  any  hobbies  would  also  be  in- 
cluded, as  would  unusual  relations  with  others.   In  addition, 
physical  deformities  affecting  the  patient's  personality  would 
be  listed. 

The  histories  are  prime  candidates  for  automation.   The 
patient  could  answer  periodic  updating  questionnaires  for  fam- 
ily and  social  histories  while  waiting  for  a  doctor's  appoint- 
ment.  The  personality  history  would  need  updating  from  both 
the  patient  and  the  doctor.   Assuming  highly  compressable  data, 
2000  bytes  should  be  sufficient  for  each  history.   This,  though, 
would  require  an  additional  600M  bytes  of  storage. 

The  private  doctor's  report  would  differ  somewhat  from 
a  hospital  file,  since  a  hospital  collects  a  large  amount  of 
information  in  a  short  period  of  time,  a  few  days.   On  the  other 
hand,  a  doctor  might  see  a  patient  for  a  half-hour  every  month 
or  every  six  months,  or  just  once.   A  dermatologist,  for  example, 
might  prescribe  to  a  patient  a  medication  for  a  skin  infection 
and  instruct  the  patient  not  to  return  if  the  infection  goes 
away.   The  doctor's  entry  into  CMHDB  might  only  contain  the 
SNOMed  code,  date,  prescription,  and  attending  doctor.   Rather 
than  add  four  bytes  of  reference  to  address  three,  a  miscellan- 
eous file  could  be  established  that  was  searched  by  date.   The 
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entry  in  the  directory  would  consist  of  the  SNOMed  code,  number 
of  reference  bytes,  date,  and  one  byte  pointing  to  the  address 
of  the  miscellaneous  file.   If  noticeable  activity  occurred  in 
any  one  area,  say  the  number  of  references  reached  a  certain 
number  for  a  particular  code,  a  separate  file  would  be  formed 
containing  all  entries  for  that  code.   These  entries  would  then 
be  eliminated  from  the  miscellaneous  file.   Doctors,  such  as 
dentist  and  optometrist,  would  most  frequently  use  the  miscel- 
laneous file  while  those  more  dependent  on  the  past  history  and 
present  status  of  the  patient,  such  as  general  practitioner, 
would  have  a  separate  file  for  that  patient.   The  average  stor- 
age requirements  for  a  private  doctor's  reports  are  expected  to 
be  1,000  bytes  of  compacted  information  per  patient. 
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CHAPTER  4 
CONCLUSION 

As  has  been  pointed  out,  the  technology  is  available  to 
build  a  CMHDB.   Legal  problems  and  the  traditional  way  of  doing 
things  will  inhibit  the  feasibility  and  efficiency  of  a  CMHDB. 
In  particular,  the  system  must  be  used  as  a  primary  source  of 
information.   It  will  not  be  economically  feasible  or  more  than 
a  research  toy  as  long  as  duplicate  records  are  manually  re- 
corded.  Secondly,  the  efficiency  of  the  system  will  be  greatly 
enhanced  if  problem  oriented  records  and  SNOMed  type  codes  are 
adopted.   There  is  a  trend  toward  problem-oriented  records,  but 
it  is  difficult  to  change  habits  100  years  old.   Problem-oriented 
records  allow  easy  search  and  retrieval  while  making  it  possible 
to  restrict  user  access. 

A  centralized  data  base  is  reduced,  first,  by  minimiza- 
tion of  redundancy,  and  secondly,  by  data  compaction  techniques. 
Centralization  offers  an  economically  viable  method  of  using  the 
best  equipment  for  information  storage  and  retrieval.   Finally 
and  most  importantly,  a  Community  Medical  History  Data  Base 
offers  the  most  complete  records  for  more  individualized  care. 
Such  a  system  would  be  ideal  for  a  Health  Maintenance  Organiza- 
tion (HMO).   See,  in  particular,  [53],  where  dentistry,  psychi- 
atry, and  general  medical  care  are  all  practiced  in  one  building. 

The  system  discussed  was  required  to  be  on-line  with  a 
response  that  would  satisfy  an  impatient  doctor.   The  core  of 
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the  desired  computer  must  contain  programs,  translation  tables, 
organization  charts,  user  directory,  and  300K  bytes  for  the 
table  of  patient  directory  addresses.   This  would  indicate  a 
need  of  a  computer  with  a  .75  to  1.0  million  bytes  of  core  or 
primary  storage.   The  computer  also  needs  to  be  able  to  handle 
up  to  100  requests  at  once.   This  is  based  on  the  assumption 
that  private  doctors  would  make  one  request  every  half-hour 
and  since  most  private  practitioners  keep  office  hours ,  there 
would  be  a  large  influx  of  requests  in  a  short  period  of  time 
about  8:30  a.m.   The  patient  directories  would  require  a  disk 
the  size  of  the  69. 8M  byte  IBM  M3340.   About  8  IBM  2314  Disk 
Array  units  would  be  needed  for  the  medical  files.   The  eight 
disk  array  units  would  allow  about  1.5  billion  bytes  of  stor- 
age.  If  this  was  thought  to  be  insufficient,  consideration  to 
magnetic  domain  (bubble)  memories,  charge-couple  devices  or 
optical  memories  should  be  given.   All  are  reputed  to  be  faster, 
larger,  and  less  expensive  than  disk  and  practical  within  two 
or  three  years.   Such  a  system  could  be  implemented  for  1.5 
million  dollars  annually,  including  overhead.   This  is  $3,000 
per  user,  but  cost  would  be  proportional  according  to  use. 
Most  of  the  benefits  to  the  private  doctor  would  be  intangible. 
Records  would  be  more  complete  and  readily  available.   An  in- 
crease in  speed  and  accuracy  in  information  retrieval  and  de- 
crease in  paper  and  possibly  staff  could  be  achieved.   Medical 
records  would  be  consolidated  for  more  effective  and  efficient 
use.   The  complete  records  allow  the  evaluation  of  care  rendered 
and  the  review  of  utilization  of  health  facilities,  medical  care, 
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and  services.   Cost  to  the  users  could  be  reduced  by  charging 
statisticians,  researchers,  and  educational  and  training  cen- 
ters for  use  of  CMHDB. 

It  is  hoped  this  provides  some  insights  into  the  prob- 
lems and  solutions  of  designing  a  community  medical  history 
data  base. 


51 


APPENDIX 
TESTS  GIVEN  AT  MERCY  HOSPITAL  IN  URBANA ,  ILLINOIS 
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TESTS 


FREQUENCY  PER  1000  TESTS 


SURGICAL  PATHOLOGY 


Autopsies : 

Coroner's  Case 
Mercy 

Private  Cases 
Stillborn 


Tissues : 

Bone  Marrow 

Frozen  Section 

Stone  Analysis 

Gross 

Microscopic 

Pap  Smear 

Programmed  Medical  Histories 


1 
* 

24 

21 

20 

3 


CLINICAL  PATHOLOGY 


Blood  Bank: 

Blood  Transfusions 

Transfusion  Reactions 

Crossmatch 

Type 

Rh.  Factor 

Rh.  Titer 

Coombs 

Cord  Blood  Studies 

Selectogen 

Rhogam 

Phlebotomy 

Cryoprecipitates 

Platelet  Concentration 


14 

* 

26 
49 

49 
* 
* 
* 

11 

* 
3 


Spinal  Fluid: 
Cell  Count 
Chloride 
Colloidal  Gold 
Glucose 
Pandy 
Protein 
VDRL 

Spinal  Electrophoresis 
LDH  Electrophoresis 
Spinal  Viral  Antigens 
Spinal  Isoenzymes 
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TESTS 


FREQUENCY  PER  1000  TESTS 


Biochemistry: 
Acetone 
Albumin 
Ammonia 
Amylase 
Blood  Alcohol 
BSP 

Bilirubin  (Direct  6  Indirect) 
Bilirubin  (Total  Only) 
Calcium 
Carotene 
Ceph.  Floe. 
Copper 
CPK 

Cholesterol 
Creatinine 

Creatinine  Clearance 
D-Xylose  Tolerance 
LDH 

Gastric  Analysis 
Glucose 

Glucose  Tolerance 
Icterus  Index 
Insulin  Tolerance 
Iodine  T3 
Iodine  T4 
Iodine  PBI 

Free  Thyroxine  Index 
Iron 

Iron  Binding  Capacity 
Iron  Saturation 
Lactose  Tolerance  Test 
LAP 

Lipase 
Magnesium 
NPN 

Phosphatase  (Acid) 
Phosphatase  (Alkaline) 
Phosphorous 
Oxygen  Saturation 
Total  Protein 
SMA  12/60 
Sweat  Test 
Sweat  Electrolytes 
Thymol  Turbidity 
SGOT 
SGPT 
Urea  Nitrogen  (BUN) 


* 
* 
* 
4 

* 

* 
* 
* 
* 
* 

7 
* 

3 

* 

4 
* 

27 

1 
* 
* 

3 
3 
1 
3 

* 

* 
* 

* 

* 
* 

* 

* 

* 

71 

5 
* 

6 
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TESTS 


FREQUENCY  PER  1000  TESTS 


Biochemistry  (continued) : 
Uric  Acid 
Zinc 
G6PD 
Lithium 
ALA-PDG 

Australian  Antigen 
Sodium 
Potassium 
Chloride 
Base  Excess 
Hydrogen  pH 
p02 
pC02 
Oxygen  Content 


* 
* 
* 

1 
* 

* 
21 
23 
21 
15 
15 
15 
15 

* 


HEMATOLOGY: 
CBC 

Hematocrit 
Hemoglobin 
WBC 

Differential 
Bleeding  Time 
Blood  Volume 
Clotting  Time 
Clot  Retraction 
Color  Index 
Eosinophil  Count 
Fibrinogen  (Fibrindex) 
Fibrinolysin 
LE  Prep 
Methemoglobin 
PTT 

Platelet  Count 
Reticulocyte  Count 
RBC  Count 
RBC  Indices 
RBC  Fragility 
Sedimentation  Rate 
Sickle  Cell  Prep 
Prothrombin  Time 
Peripheral  Smear 
RBC  Study  for  Basophil  Stipp 
Platelet  Concentration 
Sperm  Count 
Protamine 


95 
18 
13 
5 
2 
* 
* 

3 
* 
* 

* 
* 
* 

12 
5 
* 
* 
* 
* 
9 
3 

20 
* 

* 

* 

* 
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TESTS 


FREQUENCY  PER  1000  TESTS 


MICROBIOLOGY: 

Bacterial  Culture 
AFB  Culture 
Fungi  Culture 
Sensitivity 
Smear,  Bacterial 

AFB 

Fungi 
Fluorescent  Microscopy 
PKU 
Viral  Studies 


30 
3 
2 

17 

1 
1 
1 
* 

6 


SEROLOGY : 

Cold  Agglutination 

Febrile  Agglutination 

Antinuclear  Antibody 

ASO  Titer 

Brucella 

C-Reactive  Protein 

Gamma  Globulin 

Heterophile 

Histoplasmosis 

RA  Latex 

Rubella 

Pregnancy  Test 

Tularemia 

VDRL 

FTA 

Plasma  ** 

Darkf ield 


* 
* 
* 

* 
* 
* 
* 
* 
* 

* 

* 

62 

* 

* 


URINALYSIS: 
Routine  Ua 
Microscopic  Only 
Hemoglobin 
Bile 

Ketone  Bodies 
Glucose 
pH 

Bence  Jones  Protein 
Protein 
Albumin 
PSP 

Specific  Gravity 
Urobilinogen 
Porphyrins 
Diacetic  Acid 
Urine  Lactose 
Addis  Count 


85 

* 

* 
* 
* 

* 
* 
* 
* 
* 

* 
* 
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TESTS 


FREQUENCY  PER  1000  TESTS 


FECES: 
Bile 
Fat 

Occult  Blood 
Ova  and  Parasites 
Starch 
Trypsin 
Eosinophiles 


HORMONES: 
Aldolase 
Aldosterone 
Catecholamines 
Estrogen 
Gonadotropin 
5HIAA 

17 -Corticosteroids 
17 -Hydroxy corticosteroids 
17-Ketosteroids 
17-Ketogenic  Steroids 
Porphobilinogen 
Porphyrins 
Pregnanediol 
Pregnanetriol 
Sertonin 
Urobilinogen 
VMA 
FSH 

Testosterone 
Haptoglobins 
Masters  EKG 


FUNCTIONAL  STUDIES: 
BMR 
EEG 
EKG 

10-hr  EKG 
Pulmonary  Function 


* 

2 

32 

* 


SPECIAL  CHEMISTRY: 

Serum  Protein  Electrophoresis 

LDH  Electrophoresis 

Hgb  Electrophoresis 

Immunoglobulins 

Lipids 

Lipoprotein  Phenotyping 

Bromide  Levels 

Eatonagent  Comp .  Fixation 

Immunoglobulin  Electrophoresis 
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TESTS 


FREQUENCY  PER  1000  TESTS 


SPECIAL  CHEMISTRY  (continued) : 
Plasma  Protein  Electrophoresis 
Nitratenylsis 
Protein  Ox 
Chromosomes 
Buccal  Smear 
Estriol 
Blood  Renins 
Barbiturates 
Salicylates 
Schilling  Test 
Ewal 

Viral  Antigen  Test 
Sulfa  Level 
Triglycerides 
Amino  Acids 
Urine  for  Lead 
Osmolarity 
Haptoglobin 
Coma  Screen 
Vitamin  A 

Amniocentesis  Fluid 
Etholchloronol 
Lutenizing  Hormone 
Lead 

Plasma  Cortisol 
Beta  C  Fixation 
Delta  Levine 
Folic  Acid 
Chromium  51 
Euglobulin 
Factor  VIII 
I3AA 


* 
* 

* 
* 
* 
* 

* 

* 
* 
* 
* 

* 
* 

* 

* 
* 


Note:   Frequency  is  based  on  102,072  tests  given  over  a  ten 
month  period. 


indicates  a  frequency  of  less  than  1  per  1000  tests 


Date 


MERCY    HOSPITAL,  Utbana,  Illinois 
DOCTOR'S  ORDERS 


Date 


PROGRESS  RECORD 


" 

= ' ' 



1 

Coc 

50CT 

•  3119 

OR'S  ORDERS-PROGRESS   RECORD 
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MERCY   HOSPITAL 
Patient's   Name      


AGE  ON  ADMISSION 


SEX 


ORIGIN 


PATIENT  NUMBER 


M  O  Months  O  M       Mal# 

0  O  0,Y*  O   F      F™",u 

0  0  Years  plut  100 

N  Q  Newkom 


Qw       White       O     N       N.g,o 


ADMISSION  DATE 


Day 


a 


a 


Days   of    Week 

Q      1  Mondoy 

O    2  Tuesday 

(^}    3  Wednesday 

Q)    4  Thursday 

85  Friday 

6  Saturday 

\J    7  Sunday 


□ 


DISCHARGE  DATE 
DAY   MONTH  YEAR 


DISCHARGE    STATUS 

HOSPITAL  SERVICE 

O     1.  With  Approvol 

o 

1 

Medical 

Q     2.  Against  Advice 

o 

2  Surgery 

f~°\     3.  Ttqnsferred 

o 

3 

Pediatrics 

O    *•  Unimproved 

o 

4 

Psychiotrlc 

o 

5 

OB 

Q      S.   Dl.d  over  48  Hours 

o 

6 

NB 

Q    °-  Dr.d  under  48    Hours 

o 

7 

UROL 

\J    7.  Autopsy 

o 

e 

GYN 

Q  8.  No  Autopsy 

o 

9 

Orthopedics 

o 

10 

Ophthalmology 

o 

ii 

Otolaryngology 

o 

12 

Neurosurgery 

o 

13 

Thoracic  Surgery 

CD 


D 


PAYMENT 
O    I-  Blue  Cross 
(*\    2.    Commercial  Ins. 

O  3.  Workmans  Comp. 

y  S.  Medicare 
\J  6.  Private  Pay 
Oj  7-  Gov't  Agencies 


HEMATOLOGY 

O    I    BLEEDING  COAG  TIME 

O   2    CBC 

Q   3    BONE  MARROW 


BLOOD    TYPE         URINALYSIS 


SEROLOGY 


HEMOGLOBIN 

WHITE 

or 

BLOOD 

HEMATOCRIT 

COUNT 

o 

o 
o 
o 
o 
o 
o 
o 


1-  0* 

2-  A* 
3.  B* 

4-  AB* 
5-0- 


Ol-Don.  0'-VDRl- 

Q    2   -  Done   Later 


□ 


.J 


6- A. 

7-  B- 

8-  46- 

0~°~R"k- 

Q     A-  RH 


NUMBER  OF 
TRANSFUSIONS 


m 


m 


D 


□ 


a 


TEMPERATURE 


.D 


BLOOD    PRESSURE 


Vt 
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PATIENT  NUMBER 

ATTENDING 
PHYSICIAN 


n 


.D 


FINAL    DIAGNOSIS 

■I'll 

. 

.D 

1. 

.nr 

. 

.DL 

I.I  1 

Pathology   Rapor 

In  Chorf 

THERAPY 

O   1     Groii 

O  '     X-Roy,  RX 

\^J  2   Micro»iopic 

Q   2    Spooch 

O  3  F-s- 

O  3    Phyicol 

Q   4    Pop  Sm.or 

Q   4    Shock 

O  5    °««P- 

Q   6      Inhol. 

O5     Ti«»-  "•""> 

rod 

no  roport 

U«    No  Tin. 

Romovod 

..□ 


a 


Bactorlol  Sm.or    Q      '     SF|nal 
Culturo  O      2    Othar  Bod 

Fluid. 


X-RAY  BACTERIOLOGY 

O'  Cho.t  Q?    CNS  •  CNS  Spoeot         Q| 

Cj2  Othor  Rasp.       0^8    MommogrorrK  O  2 
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